Home networking standards, such as the Universal Plug and Play (UPnP) and Digital Living Network Alliance (DLNA), have been developed to facilitate the interconnection of media devices in the home. The UPnP and DLNA specifications and guidelines allow for the discovery of content, and the transfer of content from, for example, a Digital Media Server (DMS) to a Digital Media Renderer (DMR) or Digital Media Player (DMP). With DLNA, when copy protected content is exchanged between two interconnected devices such as a DMS and a DMP, Digital Transmission Copy Protection over IP (DTCP-IP) or Windows Media Digital Rights Management for Network Devices (WMDRM-ND) may be used for device authentication and link protection. A DMP, e.g. a set-top box, may output to a Digital Media Renderer (DMR) over a High bandwidth Digital Multimedia Interface (HDMI) using High Definition Copy Protection (HDCP). This permits the copyright owner(s) to control access to their content.
In one scenario, as depicted in FIG. 1, this is accomplished when a source device such as a DMS 20 is connected to a sink device such as a DMP 24 and there is a request to transfer content in some way (e.g., streaming) from the source device 20 to the sink (target) device 24 via an interconnection 16. In this example, both devices are connected together in close proximity such as within a home 26 or home entertainment network. The physical infrastructure could be, for example, a wireless Local Area Network (WLAN), Power-line Communications (PLC) or Multimedia over Coax Alliance (MoCA). Internet Protocol (IP) is used for transporting the media content.
Pay Content is typically managed and transferred according to the compliance rules 12 and 22 of the protection technologies employed at different points of the distribution in such known systems. For example, conditional access (CA) systems may be used to get the content from a content provider broadcast center to a set-top box acting as a DMS. The content may be then recorded to a local hard disk drive or streamed to a DMP. When recording the content, broadcast content is usually CA descrambled and re-scrambled with local copy protection, e.g. DTCP-IP, WMDRM-ND or other technology such as DRM copy protection 28.
So called “Over-the-top” (OTT) content may be delivered from the service provider already DRM encrypted. OTT content may be recorded or streamed in the home with the delivered DRM encryption without the CA decryption step. Content may be streamed so long as the target device 24 is not on a revocation list 32 stored at the source device. In some scenarios, e.g. DTCP-IP, the target device may also check to see if the source device is on a revocation list 32. This prevents a compromised source device from interoperating with non-compromised target devices. This revocation list 32 may be updated over the Internet 40 via an Internet connection 44 from a revocation database 36. However, this implementation is of limited utility due to the practical size limitations of the memory (not shown) of the source device and the large number of devices which might need to be revoked. In addition, in some cases, the updated revocation list may be blocked by the user from being received by the source device. Moreover, most such source devices do not have the ability to readily update their revocation list in a timely manner.
It should be mentioned that revocation lists are only good for certain types of security breaches where the security identity and credentials of a particular device are cloned to other devices. If this compromised identity can be discovered, e.g. by law enforcement personnel, then it can be placed in a revocation list that can be checked. But in some security breaches, it may not be possible to revoke devices because it was not an identity of a device that was compromised. For example, it might be the software implementation that allows improper behavior, e.g. copying of content that was supposed to be only streamed and then discarded.
In another example, the identity of the offending device might be synthetized at will. This might be possible, for instance if a certificate authority which signs public key certificates, were to have a private key that was breached and widely circulated. Device certificates could then be created easily by non-authorized persons. While not a breach of a certificate authority, in a real live hacking case, in 2009, it was revealed that HDCP public and private keys, widely used for the HDMI link identities, could be created at will. HDCP did not use a standard public/private key architecture, for example, using RSA or elliptic curve cryptography or any other suitable cryptography. The mathematics involved in the HDCP breach will not be explained here, but the software to create HDCP identities was published on the Internet. In such a situation, it might be impossible to detect all the fraudulent identities against a revocation list 32 due to practical storage limitations. There could be a huge number. But since they would be easy to create, they could be created and used privately. They may be undetectable. It is when a special hacking device is marketed or otherwise distributed with a fraudulent identity that exposure is possible. The target and source devices would need to check to see if their respective security identities were ones that were generated by the proper creation authority. In other words, the identities would need to be checked against a creation database, e.g. white list of known good identities.
Identities are usually serial numbers that are created in sequence. These might be guessed. And because the credentials could be faked, the credentials themselves, such as the MAC address or public key, could be checked as well. For example, did the public key presented for a particular security identity associated with a target or source device actually match that in the creation database? If not then the copy protection operation, whatever it is should not proceed. The situation with HDCP is so insecure, that ideally the technology would be replaced. But there are now hundreds of millions of devices in the field and so the content creation industry will be faced with possible content exposure through legacy devices for decades to come.
In addition, the source and target devices are built to certain hardware and software specifications called compliance rules 12 and 22. These are typically part of any security and copy protection systems, and are negotiated with the content creation industry, e.g. Hollywood studios, and other existing security systems. Conditional Access (CA) systems, such as DTCP-IPT™, WMDRM-NDT™, HDCP™, etc., all have compliance rules 12 and 22. The rules 12 and 22 allow one security system to hand-off content to another security system while maintaining a level of protection over the content. But it is difficult for devices to update the rules 12 and 22. For example, as new ways to store content become available, e.g. Blu-ray™ discs, iPOD™s, and tablets, e.g. iPAD™s, it is difficult for the devices to differentiate between these methods especially if it occurs with devices which are added downstream of the device. The original device recorded to an internal hard disk drive, but a device downstream can record to compact disc (CD) or digital versatile discs (DVD). The original security scheme may not have envisioned a detachable medium like a CD or DVD.
Compliance rules 12 may be a different than compliance rules 22 depending on the date of manufacture and when certain technologies were made available and the type of device it is, e.g. target, source, controller, etc. Because of the difficulty of updating the rules 12 and 22, they often cannot be made the same. One will be a different version then the other. Likewise, new ways to transmit content are becoming available. WI-FI or cellphone technology, such as 3G or 4G, the software has difficulty differentiating between such distribution approaches in order to possibly copy control access. As content is copied or streamed from device to device, it is difficult for an originating source or gateway device that received content earlier to maintain existing copy control over content on devices that receive it later, e.g. “downstream” of the originating or gateway device. This is especially true with so called “adaptor” devices. For example, an adaptor dongle can interface with an HDMI™ port and wirelessly transmit content to another dongle which interfaces to an HDMI port on a different device. Wireless transmission may never have been originally conceived by the HDCP security which may have assumed a wired, tethered connection using HDMI. Wireless transmission might allow new possibilities for content theft which might be disallowed under future HDCP compliance rules, but the older rules might not distinguish between wired or wireless transmission. For example, a hack might allow an entire college dormitory to view content sent wirelessly. The technology for devices is changing quickly. And it is difficult to update the security software in order to execute new compliance rules 12 and 22 to accommodate the changing landscape of technology and complexity of device interconnections. HDCP is not realistically fixable because of the huge installed base of legacy devices that cannot be upgraded and that would need to be replaced. The risks are high for the content owners. Delivery to insecure storage media or transmission media could expose content to unintended copying and redistribution and, as a result, cause a loss of revenue for the content owners.